-
Notifications
You must be signed in to change notification settings - Fork 23
Wide angle scattering events degree project #1848
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
Added wide angle event generator. Shots single (mono-energetic) electrons downstream at a configurable angle with respect to the z axis.
…cluster matching ParticleFlow.h
Added linking between Track and HCal cluster Added and refined arbitration for Track and HCal cluster matching I've implemented these algorithms as part of my bachelor degree project and I have written them very similar to the ones for the track + ecal cluster matching. I tried to stick to the existing variable "convention" but think that they might need some refinement at a later stage as "Calo" and "HadCalo" sound confusingly similar to describe the ECal and HCal respectively.
Added linking between Track and HCal cluster Added and refined arbitration for Track and HCal cluster matching I've implemented these algorithms as part of my bachelor degree project and I have written them very similar to the ones for the track + ecal cluster matching. I tried to stick to the existing variable "convention" but think that they might need some refinement at a later stage as "Calo" and "HadCalo" sound confusingly similar to describe the ECal and HCal respectively.
Added updates according to current version of trunk
|
The changes in pfReco.py and generators.py seem to have passed the basic tests. However, the ones in ParticleFlow.h and ParticleFlow.cxx have not passed the tests and I do not quite understand why. Especially in the case of ParticleFlow.h as there are only 3 lines that initialize additional parameters... when I used these codes in my own development environment, they didn't yield any errors... |
|
The conflicts shown here make me think that your branch is based off an older version of ldmx-sw. I can check locally to see what version of ldmx-sw your branch is based on: so your branch is We need to update your branch to the current version of ldmx-sw (the How to UpdateYou need to make sure your local copy of And then you can merge When I do this, I see It is up to you as the human developer to tell |
25b0f75 to
ee2cd72
Compare
|
hey @tillrue, i just started a PR with some work i did over summer. since you are anyway going to have to resolve conflicts, it's better to rebase to also, a heads-up that you need to check out your branch again since we removed some bulky git history yesterday and don't want it reintroduced from old copies. so
swing by/reach out if you need any help with all of this (beyond @tomeichlersmith's helpful pointers) |
Hi!
In my bachelor degree project, I have developed the matching logic for Tracks and HCal clusters in the ParticleFlow algorithm. Inspired by the existing code from the Track and ECal matching, I have added matching criteria such as a distance threshold between the extrapolated track and cluster, as well as a minimum and maximum energy ratio between track and cluster. For the Track-HCal matching, I have made these configurable such that they can be decided on in the future.
I have also taken care of special cases such as a Track that is matched to an ECal cluster but not to an HCal cluster and the two clusters were matched to each other. In these cases I combined them all and the output is that they appear together as Track+ECal+HCal entry. In the previous version this case would have been registred as Track+ECal and ECal+HCal cluster entries such that there would suddenly be an additional ECal cluster. However, I think the code still needs more testing and can maybe just be seen as a first draft. The "new" variable names are inspired by the existing ones, but these were sometimes a bit confusing, as Calo and HadCalo are for instance describing ECal and HCal. But i guess that can easily be fixed when the code is refined at a later stage.
The report of the project can be found here:
https://lup.lub.lu.se/student-papers/search/publication/9195974
There I also wrote about the performance of the current matching and found that the clustering can be improved. Both in a sense of optimizing the distance threshold parameter and by e.g. adding a "satellite clustering" algorithm to link multiple clusters.
What are the issues that this addresses?
Check List